Reconstructing the RIFF chunks from a file's wrapper, a crafted "cue " chunk:

cue payload = 12 bytes, count field = 0x20000000
-> reads 0x20000000 * 24 bytes from a 12-byte buffer
-> GlobalAlloc(0x20000000 * 8) wraps to 0 on Win32, the loop writes 4 GiB

FilterGetNextSpecialData takes the record count straight out of the chunk payload, which comes from WavpackGetWrapperData and so is attacker controlled, then uses it as both the GlobalAlloc size and the loop bound with no check against dwSize. "plst" has the same shape. "ltxt" copies a fixed 12 bytes into a GlobalAlloc(dwSize - 4) buffer, so a dwSize below 20 overruns the destination (and below 4 underflows the size).

Found while reading the wrapper-replay path. The encode side derives the counts from dwSize, so it is safe; the decode side trusts the stored count, so it is not.

Validate each count and size against dwSize before allocating and copying.